Within modern enterprises, large numbers of individuals and organizations are present each having different functions, organizational associations, group affiliations, and the like. A directory service can provide a repository of information about the individuals, organizations, services, affiliations and resources within an enterprise according to a particular structure that facilitates management and communication within the enterprise. In an enterprise network environment for example, a directory service can identify network users, installed software, installed hardware, permissions, and the like. Subsequent access to information can be accomplished without particular knowledge of certain aspects such as physical location or the like.
In order to provide a more uniform and wide ranging standard, access to directory information for example in complex heterogeneous computer networks is governed by standards such as those established by the International Telecommunications Unions (ITU). One such standard is the so-called directory access protocol (DAP) specified under the X.500 standard and also the international standards organization (ISO) under the ISO/IEC 9594 standard. The above noted standards provide a universal structure for electronic directories of, for example, nodes in an enterprise so that the information can become part of a global directory available to anyone in the world having access to the Internet. In accordance with X.500, a directory system agent (DSA) hosts a hierarchical database for storing the directory information for expeditious search and retrieval of information with multiple DSAs capable of being interconnected. Clients or users can access directory information through the use of an application known as a directory user agent (DUA). In a typical installation, a DUA can provide a capability for simple inquiries and can also include more features such as a graphical user interface (GUI) or the like. A directory system protocol (DSP) is also specified to control interaction between DSAs, and DUAs and DSAs such that an end user can access information in the directory without needing to know the exact location of that specific piece of information.
In accordance with X.500, each site is only responsible for its local Directory portion and as a result, updates and maintenance can be done instantly. Directory services under X.500 further provide powerful searching facilities that allow users to construct arbitrarily complex queries. Directory services under X.500 are further provided using a single homogeneous namespace to users such as under domain name service (DNS). Directory services under X.500 are defined using a structured information framework that allows for local extensions. Still further, X.500 compliant directory service can provide resident applications that require directory information, such as e-mail applications, automated resources locator applications, and special-purpose directory tools with access to huge amounts of information in accordance with a uniform structure. Since fully featured X.500 directory can be complex to implement, the lightweight directory access protocol (LDAP) was developed to provide less complex implementation. LDAP is a TCP/IP-based version of DAP primarily for use on the Internet. While much of the functionality of DAP is preserved, LDAP can be configured to query data from various proprietary and open X.500 directory services. While LDAP compliant directory services can provide standard interaction between clients having queries and other LDAP compliant servers, problems can arise in that based on the structure of the directory information tree, navigation of entries or changes to the hierarchical structure becomes difficult.
It is understood that directory services applications, and particularly user interface applications or GUIs, are typically programmed using object-oriented methodologies since object-oriented languages allow reusability and scalability of code. As will be appreciated, object-oriented GUI applications are programmed using objects. In the context of object-oriented programming, an object is a data-centric construct or abstraction that can be used to define and control the operation of the application in terms of fundamental units. For example, in an object oriented application for managing a doctor's office, one type of object might include a “patient” object. The patient object then consists of data associated with the patient such as address and account data and operations performed on the data such as billing operations and account management operations.
A typical object includes a collection of operations or methods and data or attributes that can be unique to the object and that define a set of behaviors that the object can perform or behaviors that can be performed on the object. The class of an object defines a group characteristic of an object based on one or more common properties shared by the group. For example a patient object is of the class patient. Another class of object might include “caregiver.” An instance of the object would be a particular patient object or caregiver object corresponding to an individual patient or caregiver. A class definition can define methods for constructing new object instances and also for determining the behavior of each instance of the object, which define how each instance behaves.
The class definition also includes attributes that define particular features of an instance of an object such as a salary. Object-oriented applications can include objects that may generally be divided roughly into three object types: model objects, view objects, and controller objects. Model objects generally handle operations such as manipulating data. View objects are used to support graphical presentation such as the content and operation of the GUI. Lastly, controller objects can be used handle interaction between model objects and view objects including input from external input devices such as keyboards and pointing devices. In connection with view objects, container objects can be used to represent data in structures such as folders, drawers, and file cabinets normally associated with a GUI.
Views in an LDAP directory services environment include sets of attribute information associated with an LDAP directory entry that are available to be “viewed,” for example, by a particular software application, a user, or the like. Views can be filtered depending on access permission levels or on organizational function and can be limited or expanded based on parameters such as permission levels, organizational functions, and the like. As described, an attribute is a value that describes one characteristic of an object, which can have many attributes associated with it. In a large enterprise, as people are added, move and depart from organizations, and as organizations change and are added or removed from an enterprise, attributes associated with objects in the enterprise change.
In view of the above explanations, problems can arise in that, as new attributes are added to objects within a directory, or as new container objects are added to represent changes to the enterprise, they may not be readily available to certain views within available within the enterprise. Accordingly, when changes occur to the actual structural hierarchy of the directory in terms of container objects and attributes, changes to the view should also occur. Such changes can be difficult to represent particularly in real time. In security environments, such as PKI environments, the need to accurately reflect the current state of the directory in terms of container objects further amplifies the need for rapid directory updates since failure to accurately represent the network state can lead to vulnerabilities that can be exploited.
While a general background including problems in the art are described hereinabove, with occasional reference to related art or general concepts associated with the present invention, the above description is not intending to be limiting since the primary features of the present invention will be set forth in the description which follows. Some aspects of the present invention not specifically described herein may become obvious after a review of the attendant description, or may be learned by practice of the invention. Accordingly, it is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only in nature and are not restrictive of the scope or applicability of the present invention.